System and method for sharing and transferring ownership of communications containing electronic health information

ABSTRACT

A messaging platform is configured to impose HIPAA-compliant ownership and access control on conversations between caregivers that can contain at least some protected health information (PHI) and electronic protected health information (EPHI). In one exemplary embodiment, the messaging platform can be configured to support conversations between caregivers who are actively affiliated different covered entities. As such, the messaging platform is able to maintain HIPAA-compliant ownership control when ownership of a conversation is shared amongst multiple covered entities. According to another exemplary embodiment, the messaging platform can support the transfer of the ownership of a conversation from one covered entity to another.

RELATED APPLICATIONS

The present application claims priority to U.S. Provisional PatentApplication No. 61/952,144 filed Mar. 13, 2014, U.S. Provisional PatentApplication No. 61/984,852 filed Apr. 27, 2014, U.S. Provisional PatentApplication No. 61/986,748, filed Apr. 30, 2014, U.S. Provisional PatentApplication No. 62/009,920 filed Jun. 10, 2014, and U.S. ProvisionalPatent Application No. 62/009,921 filed Jun. 10, 2014, each of which isincorporated by reference herein in its entirety.

BACKGROUND

Today we are connected by ever more powerful devices with everincreasing communication capabilities. Moreover, more and more physicalobjects or “things” are embedded with electronics, software, sensors andconnectivity to enable them to achieve greater value and service byexchanging data. As the amount of information and data being exchangedby communication and other devices increases, the ability to ensureprivacy and security of the information and data is becoming harder andharder. For business and other entities looking to take advantage ofmodern communication and device capability to gather and use data, thedifficulty in ensuring privacy and security of the data can lead toliability. A prime example of this is in the health care arena wherepatient health information is being gathered and exchanged.

The Health Insurance Portability and Accountability Act (HIPAA) of 1996imposes specific requirements on the management of Protected HealthInformation (PHI) and Electronic Protected Health Information (EPHI) bycovered entities (e.g., physicians, hospitals, and insurance providers)as well as their business associates. The Act engendered a regulatoryframework that includes the HIPAA Security Rule and HIPAA Privacy Rule(“HIPAA Rules”). Specifically, the HIPAA Security Rule mandates the useof specific physical, technical and administrative safeguards ininformation technology (IT) systems that store or transact withElectronic Protected Health Information (EPHI). Meanwhile, the HIPAAPrivacy Rule sets protocols with respect to the correction, disclosure,and notification of PHI and EPHI.

One of the most salient aspects of the HIPAA Rules, and the related actsand regulations is that covered entities are held accountable for thesecurity and management of the PHI and EPHI under their control. Inpractice, each item of PHI or EPHI is treated as being owned by at leastone covered entity. This ownership paradigm avoids ambiguity aboutliability in the event of a security breach.

In addition to the formal medical records that are traditionallymaintained for each patient, healthcare providers also routinely engagein ad hoc communication in order to coordinate and facilitate treatmentfor individual patients. Ad hoc communication can convey PHI and EPHI,and is therefore subject to the same HIPAA Rules as formal patientrecords. Nevertheless, healthcare providers must rely on legacycommunication technologies (e.g., facsimile, paging, and email) toconduct ad hoc communication. Conventional modes of communication aregenerally insecure and cannot be readily adapted to comply with HIPAArules.

SUMMARY

According to various embodiments, there is provided a HIPAA-compliantsystem and method for communicating electronic health information. Inone exemplary embodiment, message data that include at least some EPHIcan be composed, transmitted, and/or received on a messaging client(e.g., Medigram smartphone or web application). The exchange of messagedata over a network is mediated by a messaging platform (e.g., Medigramserver(s)) that imposes HIPAA-compliant ownership and access control.

In various embodiments, the messaging client can be installed on acaregiver's mobile communication device (e.g., smartphone, laptop,tablet personal computer (PC)). In some embodiments, message data istransmitted directly between the messaging platform and the messagingclient. In other embodiments, the messaging platform and the messagingclient can communicate through a compact dedicated device (CDD). In oneexemplary embodiment, the CDD can act as an intermediary recipient. Assuch, the CDD can be configured to receive message data from themessaging platform and then forward the message data to the messagingclient. In addition, the CDD can also act as an alert agent. In thiscapacity, the CDD can be configured to respond to incoming message databy providing one or more alerts to the caregiver.

In various embodiments, a first caregiver can use the messaging clientand initiate and conduct a conversation with at least a secondcaregiver. For example, the first caregiver can exchange message datawith the second caregiver. The conversation can be patient-centered andthe corresponding message data can include at least some EPHI regardinga specific patient. Alternately, the conversation can be a professionalconversation that does not relate to any particular patient.

In various embodiments, the messaging platform can attribute ownershipof the conversation to one or more covered entities based on therespective affiliations of the caregivers participating in theconversation. Accordingly, the messaging platform can further associatedata corresponding to the conversation with the covered entity. In oneexemplary embodiment, data associated with different covered entitiescan be stored separately.

In various embodiments, the messaging platform can restrictparticipation in and access to the conversation to those caregivers whoare actively affiliated with at least one of the covered entities thatown the conversation. Thus, a caregiver can be added to a conversationowned by a covered entity if the caregiver is actively associated withthe covered entity. Furthermore, a caregiver participating in aconversation can lose access to the conversation in the event that theaffiliation between the caregiver and the covered entity owning theconversation is disabled.

In various embodiments, a single caregiver can be affiliated withmultiple covered entities. Accordingly, in one exemplary embodiment, themessaging platform can allow a caregiver to participate in and accessconversations owned by a first covered entity and conversations owned bya second covered entity. Meanwhile, the caregiver interacts with asingle instance of the messaging client but is able to participate inand access conversations owned by different covered entities.

In various embodiments, the affiliation between a caregiver and acovered entity can be linked with privileges and/or restrictions. Forexample, as between one particular caregiver and the covered entity thatthe caregiver is actively affiliated with, the caregiver can haveprivileges that include, for example, but not limited to, affiliationsadministrator privilege, professional conversation initiator privilege,patient linking privilege, conversation sharing privilege, andconversation transfer privilege.

In various embodiments, ownership of a conversation can be sharedamongst different covered entities. Accordingly, in one exemplaryembodiment, the messaging platform allows a first caregiver who isaffiliated with a first covered entity and having the requisiteconversation sharing privilege to add at least a second caregiver who isaffiliated with a second covered entity as a participant in an existingpatient-centered conversation. In doing so, the messaging platform canfurther attribute ownership of the conversation to the second coveredentity in addition to the first covered entity.

In various embodiments, ownership of a conversation can be transferredfrom one covered entity to another covered entity. For example, in oneexemplary embodiment, a first caregiver who is associated with a firstcovered entity and whose association with the first covered entity islinked with a requisite conversation transfer privilege can transfer theownership of an existing patient-centered conversation from the firstcovered entity to a second covered entity. In other embodiments, thefirst caregiver having the requisite conversation transfer privilege canremove as participants from an existing patient-centered conversationall caregivers who are actively affiliated with one or more coveredentities. In doing so, the messaging platform can attribute ownership ofthe conversation to one or more covered entities having activelyaffiliated caregivers who remain as participants in the conversation.

Other features and advantages of the present invention will become morereadily apparent to those of ordinary skill in the art after reviewingthe following detailed description and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The structure and operation of the present invention will be understoodfrom a review of the following detailed description and the accompanyingdrawings in which like reference numerals refer to like parts and inwhich:

FIG. 1 is a system diagram illustrating a network environment forvarious embodiments;

FIG. 2A is a block diagram illustrating a CDD according to variousembodiments;

FIG. 2B is a system diagram illustrating a network environment forvarious embodiments;

FIG. 2C is a block diagram illustrating production servers according tovarious embodiments;

FIG. 2D is a block diagram illustrating production and backup databasesaccording to various embodiments;

FIG. 3 is a flow diagram illustrating a process for conducting aconversation according to various embodiments;

FIG. 4 is a flow diagram illustrating a process for conducting aprofessional conversation according to various embodiments;

FIG. 5 is a flow diagram illustrating a process for sharing aconversation according to various embodiments;

FIG. 6 is a flow diagram illustrating a process for transferring aconversation according to various embodiments; and

FIG. 7A illustrates a screen display according to various embodiments;

FIG. 7B illustrates a screen display according to various embodiments;

FIG. 8 is a block diagram illustrating a device according to variousembodiments.

DETAILED DESCRIPTION

Various embodiments of the systems and methods disclosed herein providefor communicating electronic health information. In the systems andmethods disclosed, users can communicate through a simple, unifiedsolution that not only provides privacy and security, but also helps theusers and the organizations they are associated with manage the privacyand security using automated, but flexible tools. Many of theembodiments describe herein are related, e.g., to covered entities thatmust comply with HIPAA. One challenge for caregivers associated withsuch entities is the ability to communicate in an easy, convenientfashion, using modern communication technology, while still ensuringthat any PHI or EPHI is tracked and maintained in a secure fashion.

The systems and methods described herein allow caregivers affiliatedwith the same or different covered entities to engage in bothpatient-centered and professional conversations. In various embodiments,a messaging platform can mediate the exchange of message data betweencaregivers engaged in conversation. In one exemplary embodiment, themessaging platform manages ownership and access to individualconversations according to HIPAA mandates. Thus, each conversation maybe owned by at least one covered entity and may be accessed bycaregivers with active affiliations with that covered entity.

After reading this description it will become apparent to one skilled inthe art how to implement the systems and methods described herein invarious alternative embodiments and alternative applications. However,although various embodiments will be described herein, it is understoodthat these embodiments are presented by way of example only, and notlimitation. As such, this detailed description of various alternativeembodiments should not be construed to limit the scope or breadth ofappended claims.

FIG. 1 is a system diagram illustrating a network environment 100configured in accordance with one example embodiment of the systems andmethods described herein. Referring to FIG. 1, a messaging platform 120can include one or more servers 122 and databases 124. In variousembodiments, the servers 122 can provide messaging functionalities builton Extensible Messaging and Presence Protocol (XMPP).

According to one exemplary embodiment, the messaging platform 120 isconfigured to transact (e.g., receive, transmit, store) message data,which can include information that is associated with various privacyand security needs or requirements. For example, the message data caninclude at least some EPHI that is covered by HIPAA security and privacymandates. As such, in addition to imposing HIPAA-compliant ownership andaccess control, as described in more detail below, the messagingplatform 120 can also be configured to encrypt at least a portion of themessage data stored in the databases 124. Moreover, the messagingplatform 120 can be configured to store one or more redundant copies ofthe message data. For example, the servers 122 and databases 124 caninclude for example, but not limited to, primary production server(s)and database(s), and standby disaster recovery server(s) anddatabase(s). The primary production database server can be configured toreplicate production data in real time to the standby disaster recoverydatabase server, which can be located in a different geographicalregion.

In various embodiments, the messaging platform 120 can communicate overa network 110 with a plurality of messaging clients, including a firstmessaging client 150, a second messaging client 160, and a thirdmessaging client 170. The network 110 may be a wired or wirelessnetwork.

In the example of FIG. 1, each of the first messaging client 150, thesecond messaging client 160, and the third messaging client 170 can beinstalled on a respective mobile communication device (e.g., smartphone,laptop, tablet PC). For example, the first messaging client 150 may bean iOS client using the XMPP Framework while the second messaging client160 may be an Android client using the Smack XMPP library. Meanwhile,the third messaging client 170 may be a web client. Thus, according tosome embodiments, the web messaging client may be a Ruby on Railsapplication that uses the Ember and Jquery Javascript frameworks withthe Strophe.js library for XMPP.

In various embodiments, each of the first messaging client 150, thesecond messaging client 160, and the third messaging client 170 can beconfigured to compose, transmit, and receive message data. Moreover, thefirst messaging client 150, the second messaging client 160, and thethird messaging client 170 can store and provide access to a local cacheof message data. In at least one exemplary embodiment, the firstmessaging client 150, the second messaging client 160, and the thirdmessaging client 170 can be configured to encrypt the correspondinglocal cache of message data.

Referring again to FIG. 1, each of the first messaging client 150, thesecond messaging client 160, and the third messaging client 170 can beassociated with an individual user. In one exemplary embodiment, eachmessaging client may be associated with a particular caregiver (e.g.,physician, nurse). For example, as shown in FIG. 1, the first messagingclient 150 is associated with a Caregiver A, the second messaging client160 is associated with a Caregiver B, and the third messaging client 170is associated with a Caregiver C.

In various embodiments, each of Caregiver A, Caregiver B, and CaregiverC can be affiliated with one or more covered entities. For example, aphysician may be affiliated with one or more hospitals. As shown in FIG.1, Caregiver A is affiliated with a Covered Entity A and a CoveredEntity B. Meanwhile, Caregiver B is affiliated with Covered Entity A andCaregiver C is associated with Covered Entity B. As described in detailbelow, Caregivers A, B and C can use their devices 150, 160, and 170,respectively, to communicate information with each other that mayinclude PHI. Messaging platform 120 can, however, impose HIPAA-compliantownership and access control.

As described above, devices 150, 160, and 170 generally comprisestandard, or off the shelf communication devices, such as smartphones,tablets, or laptops. In certain instances, the use of such devices maynot be possible. For example, often in a hospital setting, such devicescannot be used because of a lack of proper network access or otherrestrictions. As such, in certain embodiments, a specialized device maybe needed to enable the communication of information and data describedherein. Such a device is described with respect to FIGS. 2A and 2B.

Compact Dedicated Device (CDD)

FIG. 2A is a block diagram illustrating an CDD 200 according to variousembodiments. As shown in FIGS. 2A and 2B, CDD 200 can include a controlunit 210, a first communication unit 220, a second communication unit230, a first antenna 225, a second antenna 235, a storage unit 240, analert module 250, and a battery 260.

In various embodiments, the CDD 200 can be a device that is capable oflong- and short-range wireless communication. Thus, in one exemplaryembodiment, the first communication unit 220 can include a radiofrequency (RF) chain that is configured to receive message data that isbroadcast by the messaging platform 120 via a paging system. Meanwhile,the second communication unit 230 can include a RF chain that isconfigured to communicate with a mobile communication device via one ormore wireless personal area network (PAN) technologies. For example, theCDD 200 can be paired with a mobile communication device usingBluetooth® technology. Alternately or in addition, the CDD 200 cancommunicate with a mobile communication device via near fieldcommunication (NFC). A person having ordinary skill in the art canappreciate that the first communication unit 220 and the secondcommunication unit 230 can be configured to communicate using differentwireless technologies as well.

In various embodiments, the control unit 210 can be configured tocontrol the overall operation of the CDD 200 including controlling thefunctions of the first communication unit 220, the second communicationunit 230, the storage unit 240, and the alert module 250. In variousembodiments, the control unit 210 can be, for example, but not limitedto, a microprocessor or a microcontroller.

In various embodiments, the storage unit 240 can include writablenon-volatile memory to store one or more pager identifiers, paringinformation for a wireless PAN network, and message data received fromthe messaging platform 120. The storage unit 240 can further includenon-volatile program memory. In various embodiments, at least some ofthe application programs stored at the storage unit 240 can be executedby the control unit 210 for the operation of the CDD 200.

In various embodiments, the alert module 250 can include one or moretypes of hardware including, for example, but not limited to, a vibratorcapable of generating tactile alerts, a speaker capable of generatingaudible alerts, and a display capable of generating visual alerts (e.g.,light-emitting diode (LED)).

In various embodiments, the storage unit 240 can be configured to storeapplication programs, application data, and user data. In variousembodiments, at least some of the application programs stored at thestorage unit 240 can be executed by the control unit 210 for theoperation of the mobile communication device 200.

In various embodiments, the CDD 200 can be powered in full or in part bythe battery 260. According to one exemplary embodiment, firmware on theCDD 200 monitors the charge state of the battery 260. In someembodiments, the CDD 200 can be configured to provide an alert using thealert module 250 when the battery 260 approaches a discharged state. TheCDD 200 can be further configured to transmit the charge state of thebattery 260 to a corresponding messaging client installed on a mobilecommunication device that is paired with the CDD 200.

Although not shown in FIG. 2A, the CDD 200 can also be powered in fullor in part through an audio connector. In one exemplary embodiment, thebattery 260 of the CDD 200 can be charged by connecting the CDD 200 viathe audio connector to a mobile communication device that is paired orotherwise associated with the CDD 200.

Although not shown in FIG. 2A, according to one exemplary embodiment,the CDD 200 can also be charged using a bulk charging station. The bulkcharging station is capable of simultaneously charging multiple CDDs. Invarious embodiments, connecting the CDD 200 to a bulk charging stationcan cause firmware on the CDD 200 to wipe at least a portion of thenon-volatile memory that is included in the storage unit 240. Forexample, connecting the CDD 200 to a bulk charging station can causefirmware on the CDD 200 to wipe data including, for example, but notlimited to, the pager identifier associated with the CDD 200, paringinformation for the wireless PAN network, and message data received fromthe messaging platform 120.

FIG. 2B is a system diagram illustrating a network environment 205 thatcan support or integrate a CDD 200 in accordance with one exampleembodiment. Referring to FIGS. 1-2B, the messaging platform 120 cancommunicate with the CDD 200 instead of directly with a mobilecommunication device 270 of Caregiver A.

According to one exemplary embodiment, the first messaging client 150installed on the mobile communication device 270 can be configured tocommunicate with the CDD 200 over via a PAN 260 using the secondcommunication unit 230. In various embodiments, the CDD 200 is alsoconfigured to communicate with the messaging platform 120 over thenetwork 110 using the first communication unit 220.

In some embodiments, the messaging platform 120 can transmit messagedata to the mobile communication device 270 over the network 110. At thesame time, the messaging platform 120 can broadcast, via a pagingsystem, notifications that alerts Caregiver A to the availability ofmessage data. According to one exemplary embodiment, the messagingplatform 120, the paging system and the CDD 200 may be configured toimplement a general purpose mobile push notification service. Thus, theCDD 200 is configured to receive the notifications but not message dataover the paging system from the messaging platform 120. The CDD 200 canbe configured to forward the notification to the mobile communicationdevice 270 in response to receiving the notifications from the messagingplatform 120. Moreover, the CDD 200 can be configured to generate analert using the alert module 250. As such, Caregiver A may be made awareof the availability of message data at the mobile communication device270 but the message data is not transmitted over an insecure pagingsystem to the CDD 200. In some embodiments, the general purpose mobilepush notification service is made available to other mobile applicationor service providers, including zero or more competitive messagingplatforms. Thus the messaging platform 120, the paging system and theCDD 200 provide a general purpose mobile push notification service thatcan alert Caregiver A of the availability of data when mobilecommunication device 270 is unable to communicate directly over network110.

In another exemplary embodiment, the CDD 200 can be configured toreceive message data from the messaging platform 120 over a pagingsystem or the network 110, and then forward the message data to thefirst messaging client 150 via the PAN 260.

According to one exemplary embodiment, the CDD 200 is associated with aunique pager identifier. The messaging platform 120 can be configured tostore a device list that correlates the pager identifier of the CDD 200with the mobile communication device 270. Thus, when the messagingplatform 120 receives message data that is intended for the mobilecommunication device 270 of Caregiver A, the messaging platform can usethe device list to determine the pager identifier of the CDD 200. Invarious embodiments, the messaging platform 120 can be configured tobroadcast the pager identifier of the CDD 200 along with the messagedata intended for the mobile communication device 270. Meanwhile, theCDD 200 can determine whether message data is intended for the mobilecommunication device 270 based on the pager identifier that istransmitted with the message data. The CDD 200 can transmit message datathat is intended for the mobile communication device 270 to the mobilecommunication device 270 using. Alternately, the CDD 200 can disregardand not transmit message data that is not intended for the mobilecommunication device 270.

In one exemplary embodiment, in response to receiving message data fromthe messaging platform 120, the CDD 200 can generate an alert using thealert module 250. In various embodiments, the CDD 200 generates alertsbased on one or more alert rules. For example, the CDD 200 can beconfigured to generate an alert if the message data is not successfullyforwarded to the first messaging client 150 within a predeterminedamount of time. Alternately, the CDD 200 can be configured to always ornever generate an alert, regardless of whether the message data receivedfrom the messaging platform 120 is successfully forward to the firstmessaging client 150.

In one exemplary embodiment, the message data that is communicatedbetween the messaging platform 120, the CDD 200, and the first messagingclient 150 installed on the mobile communication device 270 isencrypted. For example, the messaging platform 120 can encrypt themessage data prior to transmitting the message data to the CDD 200. Invarious embodiments, the CDD 200 is not provisioned with a key todecrypt the message data. Thus, in various embodiments, the CDD 200 doesnot decrypt the message data. Instead, the CDD 200 can be configured toforward the still encrypted message data to the first messaging client150. Meanwhile, in various embodiments, the first messaging client 150can be provisioned with the key required for decrypting the messagedata. Thus, in various embodiments, the message data is not decrypteduntil it is received at the mobile communication device 270. Thus, invarious embodiments, loss of the CDD 200 or compromise of the datastored on the CDD 200 does not constitute a breach of EPHI.

FIG. 2C is a block diagram illustrating production servers 215 accordingto various embodiments. Referring to FIGS. 1 and 2C, in variousembodiments, the production servers 215 may implement the servers 122 ofthe messaging platform 120.

In various embodiments, the messaging platform 120 can be implementedusing a hybrid cloud infrastructure that includes virtual cloud serversfor applications and services as well as physical servers for databasestorage.

FIG. 2D is a block diagram illustrating production and backup databases255 according to various embodiments. Referring to FIGS. 1 and 2D, invarious embodiments, the production and backup databases 255 canimplement the databases 124 of the messaging platform 120.

Again referring to FIGS. 1 and 2D, according to one exemplaryembodiment, a primary production database can be hosted on a dedicatedphysical server located in one geographic region (e.g., Chicago, Ill.).In various embodiments, production data is replicated in real time fromthe primary database server to a standby disaster recovery databaselocated in a different geographical region (e.g., Dallas, Tex.).

In order to restrict access to the EPHI contained in the production andbackup databases 255, there can be three instances of the productiondatabase. For example, the instances of the production database caninclude a primary production instance, a warm disaster recovery instancethat receives continuous updates from the primary production instances,and a production-test instance used for pre-release quality assurancetesting. According to one exemplary embodiment, daily backups aremaintained offline on the disaster recovery database server.

HIPAA-Compliant Ownership and Access Control

As noted above, the systems shown in FIGS. 1 and 2B can implementworkflow processes that maintain privacy and security for, e.g., ad hoccommunications. FIG. 3 is a flow diagram illustrating a process 300 forconducting a conversation according to various embodiments. Referring toFIGS. 1 and 3, in various embodiments, the process 300 can be performedby the messaging platform 120.

The messaging platform 120 can be configured to receive an indicationinitiate a conversation from a messaging client associated with a firstcaregiver actively affiliated with a first covered entity and a secondcovered entity (302). For example, Caregiver A can use the firstmessaging client 150 to start a new conversation. As will be describedin more detail below, the conversation can be a patient-centeredconversation or a professional conversation that does not relate to aspecific patient.

In response to receiving the indication, the messaging platform 120 canbe configured to identify a second caregiver actively affiliated withthe first covered entity and a third caregiver actively affiliated withthe second covered entity as authorized participants in the conversationbased on a respective active affiliations of the first caregiver, thesecond caregiver, and the third caregiver (304). For example, CaregiverA is actively affiliated with Covered Entity A and Covered Entity B. Assuch, HIPAA mandates permit Caregiver A to conduct conversations (e.g.,patient-centered) with both Caregiver B and Caregiver C. The messagingplatform 120 can be configured to cause the first messaging client 150to indicate to Caregiver A that Caregiver B and Caregiver C areauthorized participants that may be added to the conversation. A personhaving ordinary skill in the art can appreciate that the first messagingclient 150 can indicate many additional authorized participants based onthe active affiliations between various caregivers and at least CoveredEntity A and Covered Entity B.

Continuing with the example shown in FIG. 3, the messaging platform 120can be configured to receive an indication from the first caregiver toinclude at least one of the second caregiver and the third caregiver inthe conversation (306). For example, Caregiver A can add Caregiver B tothe conversation since both Caregiver A and Caregiver B are activelyaffiliated with at least one common covered entity (e.g., Covered EntityA). Alternately, Caregiver A can add Caregiver C to the conversation asboth Caregiver A and Caregiver C are actively affiliated with CoveredEntity B.

In response to the indication to include at least one of the secondcaregiver and the third caregiver in the conversation, the messagingplatform 120 can be configured to determine a number of common coveredentities having active affiliations with every participant in theconversation (308). For example, Caregiver A and Caregiver B can beactively affiliated with a single covered entity (e.g., Covered EntityA). Alternately, Caregiver A and Caregiver B can both be activelyaffiliated with more than one common covered entity. For instance,Caregiver A and Caregiver B can be affiliated with both Covered Entity Aand Covered Entity B.

If the messaging platform 120 determines that the number of commoncovered entities having active affiliations with every participant inthe conversation is greater than one (309-Y), the messaging platform 120can be configured to select at least one of the common covered entities(310) and attribute ownership of the conversation to the selectedcovered entity (312). For example, the messaging platform 120 can beconfigured to select at least one of the common covered entities basedon input from one of Caregiver A, Caregiver B, or any other appropriatepersonnel from Covered Entity A and/or Covered Entity B. Thus, ifCaregiver A and Caregiver B are actively associated with both CoveredEntity A and Covered Entity B, Caregiver A or Caregiver B can indicateto the messaging platform 120 that ownership of the conversation shouldbe attributed to Covered Entity A and/or Covered Entity B.

Moreover, the messaging platform 120 can associate data corresponding tothe conversation with the selected covered entity. As such, a caregiverwho is not actively affiliated with the selected covered entity cannotaccess data corresponding to the conversation.

In addition, the messaging platform 120 can be configured to exclude oneor more caregivers not actively affiliated with the selected coveredentity as authorized participants in the conversation (314). Forexample, based on input from Caregiver A and/or Caregiver B, themessaging platform 120 can attribute ownership of the conversation toCovered Entity A. Meanwhile, Caregiver C is not actively affiliated withCovered Entity A. As such, the messaging platform 120 can be configuredto exclude Caregiver C as an authorized participant in the conversationowned by Covered Entity A.

Otherwise, if the messaging platform 120 determines that the number ofcommon covered entities having active affiliations with everyparticipant in the conversation is not greater than one (309-N), themessaging platform 120 can be configured to attribute ownership of theconversation to the common covered entity (316). For example, themessaging platform 120 can attribute ownership of the conversation toCovered Entity A since Caregiver A and Caregiver B are both activelyaffiliated with only Covered Entity A. The messaging platform 120 canassociated data corresponding to the conversation with Covered Entity Aand prevent caregivers not actively affiliated with Covered Entity Afrom accessing the data.

Moreover, the messaging platform 120 can be configured to exclude one ormore caregivers not actively affiliated with the common covered entityas authorized participants in the conversation (318). For example,Caregiver C is actively affiliated with Covered Entity B but not withCovered Entity A. Thus such, the messaging platform 120 can beconfigured to exclude Caregiver C as an authorized participant in theconversation owned by Covered Entity A.

In this manner, in various embodiments, the messaging platform 120 canbe configured to implement HIPAA-compliant access control to theconversation. Thus, a caregiver can participate in and/or otherwise haveaccess to a conversation if the caregiver has and maintains an activeaffiliation with at least one of the covered entities owning theconversation. For example, both Caregiver A and Caregiver B canparticipate in and access a patient-centered conversation owned byCovered Entity A. However, if the affiliation between Caregiver A andCovered Entity A is deactivated, then Caregiver A can no longerparticipate in or have access to the conversation owned by CoveredEntity A.

Now that the conversation has been generated and assigned to a specificcovered entity, the message data that is associated with thatconversation can be stored, e.g., in the databases 124. For example, themessaging platform 120 can include records associated with andmaintained for each of the associated covered entities, in this caseCovered Entities A and B. The messages being communicated between, e.g.,Caregiver A and Caregiver B can be passed through platform 120 under thecontrol of the corresponding messaging clients (e.g., the firstmessaging client 150 and the second messaging client 160). In thismanner, the messages can be captured and kept as a record associatedwith the correct covered entity.

In certain embodiments, the records maintained by system 120 can beexported as electronic medical records (EMRs) maintained by a particularcovered entity.

Patient-Centered Conversation and Professional Conversation

The messaging platform 120 permits caregivers to engage in differenttypes of conversations. In various embodiments, the messaging platform120 can be configured to support patient-centered conversations. Apatient-centered conversation relates to a specific patient. As will bedescribed in more detail below, a patient can be associated with one ormore covered entities (e.g., Covered Entity A and/or Covered Entity B).In one exemplary embodiment, the messaging platform 120 can beconfigured to restrict ownership of a patient-centered conversationregarding a patient to the one or more covered entities that areassociated with the patient.

In various embodiments, the messaging platform 120 can be configured toalso support professional conversations. A professional conversation issuitable for non-patient-centered professional communication and cantake place between two caregivers who do not have active affiliationswith at least one common covered entity. For example, Caregiver B andCaregiver C can engage in a professional conversation via the messagingplatform 120. Caregivers engaged in a professional conversation disclosehealth information that does not meet the criteria for PHI or EPHI.Nevertheless, for reasons of caution and convenience, professionalconversations can be conducted via the messaging platform 120 and inaccordance with HIPAA mandates.

In various embodiments, the messaging platform 120 can be configured toattribute ownership of a professional conversation to at least onecovered entity even though PHI or EPHI would not be disclosed during theprofessional conversation. As such, the messaging platform 120 maintainsaccountability in the event that health information disclosed within aprofessional conversation is later determined to have been improperlydisclosed and to meet the legal standard for PHI or EPHI.

In various embodiments, a caregiver can be required to have therequisite privilege with respect to a particular covered entity toinitiate a professional conversation (e.g., professional conversationinitiator privilege). For example, the affiliation between Caregiver Band Covered Entity A can be linked with a professional conversationinitiator privilege. Thus, in order to for Caregiver B who is activelyaffiliated with Covered Entity A to initiate a professional conversationwith Caregiver C who is affiliated with a Covered Entity B, themessaging platform 120 can be configured to determine whether CaregiverB has the requisite professional conversation initiator privilege.

FIG. 4 is a flow diagram illustrating a process 400 for conducting aprofessional conversation according to various embodiments. Referring toFIGS. 1 and 4, the process 400 can be performed by the messagingplatform 120.

In various embodiments, the messaging platform 120 can be configured toreceive an indication from a messaging client associated with a firstcaregiver actively affiliated with a first covered entity to initiate aprofessional conversation with a second caregiver (402). The firstcaregiver and the second caregiver can both be actively affiliated withthe same first covered entities. For example, Caregiver A can use thefirst messaging client 150 to initiate a professional conversation witheither Caregiver B or Caregiver C. However, the messaging platform 120can also support professional conversations between caregivers who arenot actively affiliated with the same covered entities. For example,Caregiver B can use the second messaging client 160 to initiate aprofessional conversation with Caregiver C. Using the first messagingclient 150, Caregiver A can also initiate a professional conversationthat includes both Caregiver B and Caregiver C.

In response to the indication, the messaging platform 120 can determinewhether the affiliation between the first caregiver and the firstcovered entity is linked with a privilege to initiate a professionalconversation (403). For example, Caregiver A can have the requisiteprofessional conversation initiator privilege with respect to CoveredEntity A, which allows Caregiver A to initiate a professionalconversation with caregivers who are and who are not actively affiliatedwith Covered Entity A.

If the messaging platform 120 determines that the affiliation betweenthe first caregiver and the first covered entity is linked with theprivilege to initiate a professional conversation (403-Y), then themessaging platform 120 can be configured to include the first caregiverand the second caregiver as participants in a professional conversation(404). Furthermore, the messaging platform 120 can be configured toattribute ownership of the professional conversation to the firstcovered entity (406).

On the other hand, the messaging platform 120 can determine that theaffiliation between the first caregiver and the first covered entity isnot linked with the privilege to initiate a professional conversation(403-N). As such, the messaging platform 120 can cause a messagingclient associated with the first caregiver to notify the first caregiverthat the first caregiver does not have professional conversationinitiator privilege for the first covered entity (408).

HIPAA-Compliant Ownership Sharing

In various embodiments, the messaging platform 120 can be configured toattribute ownership of a conversation to more than one covered entity.In particular, the messaging platform 120 is configured to maintainHIPAA compliance while sharing ownership of a patient-centeredconversation amongst multiple covered entities. As such, caregiversactively affiliated with different covered entities are able toparticipate in and access the same patient-centered conversation.

For example, Caregiver A can have the requisite conversation sharingprivilege with respect to Covered Entity A and/or Covered Entity B.Thus, Caregiver A can add Caregiver C to the conversation owned byCovered Entity A even though Caregiver C is actively affiliated withCovered Entity B and not Covered Entity A. In doing so, the messagingplatform 120 can attribute ownership of the conversation to both CoveredEntity A and Covered Entity B.

FIG. 5 is a flow diagram illustrating a process 500 for sharing aconversation according to various embodiments. Referring to FIGS. 1 and5, in various embodiments, the process 500 can be performed by themessaging platform 120.

In various embodiments, the messaging platform 120 can be configured toreceive an indication from a messaging client associated with a firstcaregiver actively affiliated with the first covered entity to include asecond caregiver actively affiliated with a second covered entity in aconversation owned by the first covered entity (502). For example,Caregiver B, who is actively affiliated with Covered Entity A, may beengaged in a conversation that is owned by Covered Entity A. Caregiver Bcan use the first messaging client 150 to indicate to the messagingplatform 120 to include Caregiver C in the conversation. Caregiver C,however, is actively affiliated with Covered Entity B and not CoveredEntity A. Thus, in some embodiments, the indication from Caregiver B caninclude a selection of the Covered Entity B as a new covered entity. Inresponse to the selection of the Covered Entity B, the messagingplatform 120 can provide, via the first messaging client 150, one ormore caregivers who are actively affiliated with Covered Entity B.Caregiver B can then select Caregiver C from the one or more caregiversactively affiliated with Covered Entity B.

Alternately, in other embodiments, the indication from Caregiver B caninclude a request to specifically include Caregiver C as a new caregiverin the conversation. For example, in some embodiments, Caregiver B canprovide a unique communication enabling personal identifier (e.g., emailaddress, mobile phone number) for Caregiver C.

In response to the indication from the first caregiver, the messagingplatform 120 can determine whether the affiliation between the firstcaregiver and the first covered entity is linked with a privilege toshare the conversation (503). For example, Caregiver A can have therequisite conversation sharing privilege with respect to Covered EntityA, which allows Caregiver A to share conversations owned by CoveredEntity A in which Caregiver A is a participant.

If the messaging platform 120 determines that the affiliation betweenthe first caregiver and the first covered entity is linked with theprivilege to share the conversation (503-Y), then the messaging platform120 can be configured to include the second caregiver in theconversation owned by the first covered entity (504). Furthermore, themessaging platform 120 can be configured to attribute ownership of theconversation to the first covered entity and the second covered entity(506). As such, more than one covered entities (e.g., both CoveredEntity A and Covered Entity B) can have accountability in the event thathealth information disclosed within the conversation is breached.

In some embodiments, prior to including Caregiver C in the conversation,the messaging platform 120 can be configured to obtain a legally bindingdigital signature from Caregiver C. For example, the messaging platform120 can be configured to request, via the third messaging client 170,confirmation that Caregiver C has received HIPAA training in accordancewith HIPAA regulations, and agrees to comply with HIPAA regulations fortransmission and access to message data that is exchanged via themessaging platform 120. The messaging platform 120 can further obtainconfirmation that Caregiver C is engaged in the direct care of a patientthat is the subject of the shared patient-centered conversation.

In some embodiments, the messaging platform 120 can be configured toreceive an indication from a messaging client associated with a firstcaregiver actively affiliated with a first covered entity to include asecond caregiver D (not shown), who is not yet a user of the messagingplatform 120. For example, in some embodiments, Caregiver B can providea unique communication enabling personal identifier such as an emailaddress or mobile phone number for Caregiver D to the messaging platform120. The messaging platform 120 can be configured to make use of theunique communication enabling personal identifier to transmit aninvitation to Caregiver D to become a user of the messaging platform120. In some embodiments, prior to including Caregiver D in theconversation, the messaging platform 120 can be configured to obtain alegally binding digital signature from Caregiver D as described above.

On the other hand, the messaging platform 120 can determine that theaffiliation between the first caregiver and the first covered entity isnot linked with the privilege to share the conversation (503-N). Forexample, Caregiver A can have conversation sharing privilege withrespect to Covered Entity B but not Covered Entity A. As such, themessaging platform 120 can be configured to exclude the second caregiveras an authorized participant in the conversation owned by the firstcovered entity (508).

In various embodiments, the messaging platform 120 can be configured toattribute ownership of the conversation to the first covered entity andnot the second covered entity (510). Additionally, in some embodiments,the messaging platform 120 can cause a messaging client associated withthe first caregiver to notify the first caregiver that the firstcaregiver does not have conversation sharing privilege for the firstcovered entity (512).

HIPAA-Compliant Ownership Transfer

In various embodiments, the messaging platform 120 can be configured totransfer ownership of a conversation from one covered entity to another.For instance, a patient may be transferred from one facility (e.g.,hospital) to another facility (e.g., rehabilitation center). Thus, apatient-centered conversation can initially include caregivers havingactive affiliations with both Covered Entity A and Covered Entity B. Forexample, Caregiver A, Caregiver B, and Caregiver C can all be engaged ina patient-centered conversation that is initially owned by both CoveredEntity A and Covered Entity B.

As the patient's care is gradually transferred from Covered Entity A toCovered Entity B, the patient-centered conversation can eventuallyinclude only caregivers who are actively affiliated with Covered EntityB (e.g., Caregiver A and Caregiver C). For example, Caregiver A and/orCaregiver B can have the requisite conversation transfer privilege withrespect to Covered Entity A. The Caregiver A or Caregiver B can transferownership of the conversation from Covered Entity A to Covered Entity B.In response to this transfer of ownership, the messaging platform 120can remove caregivers who are actively affiliated with Covered Entity Abut not Covered Entity B as participants from the conversation. As aresult, Caregiver B will no longer be able to participate in and accessthe conversation.

FIG. 6 is a flow diagram illustrating a process 600 for transferring aconversation according to various embodiments. Referring to FIGS. 1 and6, in various embodiments, the process 600 can be performed by themessaging platform 120.

In various embodiments, the messaging platform 120 can be configured toreceive an indication from a messaging client associated with a firstcaregiver actively affiliated with a first covered entity to transferownership of a conversation from the first covered entity to a secondcovered entity (602). According to one exemplary embodiment, themessaging platform 120 can be configured to allow a caregiver totransfer ownership of a conversation whether or not the caregiver is aparticipant in the conversation. Alternately, the messaging platform canbe configured to allow caregivers who are participants in a conversationto transfer ownership of the conversation.

In response to receiving the indication, the messaging platform 120 canbe configured to determine whether the affiliation between the firstcaregiver and the first covered entity is linked with a privilege totransfer the conversation (603).

The messaging platform 120 can determine that the affiliation betweenthe first caregiver and the first covered entity is linked with theprivilege to transfer the conversation (603-Y). As such, the messagingplatform 120 can be configured to attribute ownership of theconversation to the second covered entity and not the first coveredentity (604). Transferring ownership of a conversation from one coveredentity from another also transfers accountability from one coveredentity to anther in the event that health information disclosed withinthe conversation is breached. For example, Covered Entity B instead ofCovered Entity A can be held responsible for breaches of any PHI or EPHIcontained within the conversation.

In addition, the messaging platform 120 can be configured to remove asparticipants in the conversation one or more caregivers who are notactively affiliated with the second covered entity (606). For example,Caregiver B is actively affiliated with only Covered Entity A. Thus,once the ownership of the conversation is transferred from CoveredEntity A to Covered Entity B, the messaging platform 120 can beconfigured to remove Caregiver B as a participant from the conversation.Consequently, Caregiver B can no longer participate in or access theconversation.

Alternately, the messaging platform 120 can determine that theaffiliation between the first caregiver and the first covered entity isnot linked with the privilege to transfer the conversation (603-N).Accordingly, the messaging platform 120 can be configured to continueattributing the ownership of the conversation to the first coveredentity (608). Moreover, the messaging platform 120 can be configured tocause a messaging client associated with the first caregiver to notifythe first caregiver that the first caregiver does not have conversationtransfer privilege for the first covered entity (610).

Patient-Covered Entity Associations

According to one exemplary embodiment, the messaging platform 120 can beconfigured to maintain a patient list that includes identificationattributes including, for example, but not limited to, patient name,birthdate, contact information, and social security number. In variousembodiments, the messaging platform 120 can be configured to maintainassociations between a patient and one or more covered entities. Forexample, a patient can be associated with Covered Entity A and/orCovered Entity B.

In various embodiments, the affiliation between a covered entity and acaregiver can be linked with a privilege to link a patient in thepatient list to a conversation owned by one or more covered entities.For example, Caregiver A can have patient linking privilege with respectto Covered Entity A and/or Covered Entity B.

In some embodiments, ownership of a patient-centered conversationregarding a specific patient can be restricted to the one or morecovered entities that are associated with the patient. Thus, in variousembodiments, in response to an indication from Caregiver A to link aconversation owned by Covered Entity A to a patient, the messagingplatform 120 can be configured to determine whether the patient isassociated with Covered Entity A.

Caregiver-Covered Entity Affiliations and Privileges

In various embodiments, the messaging platform 120 can be configured toupdate, track, and store affiliations between caregivers and coveredentities. To ensure compliance with HIPAA mandates, the messagingplatform 120 can be configured to restrict participation in and accessto conversations owned by a covered entity to caregivers having activeaffiliations with the covered entity.

For example, while Caregiver A and Caregiver B are both activelyaffiliated with Covered Entity A, both Caregiver A and Caregiver B canbe engaged in a conversation. The conversation can be a patient-centeredconversation or a professional conversation that does not relate to anyspecific patient. In various embodiments, the messaging platform 120 canbe configured to attribute ownership of the conversation betweenCaregiver A and Caregiver B to Covered Entity A.

In various embodiments, the affiliation between Caregiver A and CoveredEntity A can be suspended temporarily or be terminated permanently.Consequently, Caregiver A is no longer actively affiliated with CoveredEntity A. As such, the messaging platform 120 can be configured toremove Caregiver A as a participant in the conversation betweenCaregiver A and Caregiver B. Moreover, the messaging platform 120 can beconfigured to prohibit Caregiver A from accessing the conversation. Inaddition, when another caregiver who is actively affiliated with CoveredEntity A (e.g., Caregiver B) initiates a patient-centered conversationowned by Covered Entity A, the messaging platform 120 can be configuredto not identify Caregiver A as an authorized participant in theconversation.

In various embodiments, the affiliation between a caregiver and acovered entity can be linked with a privilege to administrateaffiliations. For example, the affiliation between Caregiver A andCovered Entity A can be linked with an affiliation administratorprivilege. According to one exemplary embodiment, a caregiver havingaffiliation administrator privilege for a covered entity is able add,activate, or reactivate an affiliation between another caregiver and thecovered entity temporarily, permanently, and/or on a probationary basis.Alternately or in addition, the caregiver is able to deactivate orremove an affiliation between another caregiver and the covered entitytemporary, permanently, and/or on a probationary basis.

FIG. 7A illustrates a screen display 700 according to variousembodiments. Referring to FIGS. 1 and 7A, the screen display 700 can bepart of the graphic user interface (GUI) provided by a messaging client(e.g., the first messaging client 150). As shown in FIG. 7A, the screendisplay 700 can show one or more conversations that a caregiver isengaged in. In one exemplary embodiment, the messaging client can beconfigured to display list enumerating the topic of each conversation.For example, Caregiver A can be engaged in multiple conversationsincluding, for example, but not limited to, a patient-centeredconversation regarding “Patient-John Doe.”

FIG. 7B illustrates a screen display 750 according to variousembodiments. Referring to FIGS. 1 and 7B, the screen display 750 canalso be a part of the GUI provided by the messaging client (e.g., thefirst messaging client 150). As shown in FIG. 7B, the messaging clientcan be configured to display a specific conversation, including messages(e.g., text, photographs) that have been exchanged during the course ofthe conversation. For example, as shown in FIG. 7B, a caregiver isengaged in a patient-centered conversation regarding “Patient—JamesHafner.”

FIG. 8 illustrates a device 800 that is suitable for use in someembodiments of the systems and methods described herein. In someembodiments, the device 800 can be used to implement any of Devices131-133 described with respect to FIGS. 1 and 2. In various embodiments,the device 800 can be used as is or in conjunction with one or more ofthe mechanisms or processes described above, and can representcomponents of server(s), user system(s), and/or other devices describedherein. The device 800 can be a server or any conventional personalcomputer, or any other processor-enabled device that is capable of wiredor wireless data communication. Other computer systems and/orarchitectures can be also used, as will be clear to those skilled in theart.

The device 800 preferably includes one or more processors, such as aprocessor 810. Additional processors can be provided, such as anauxiliary processor to manage input/output, an auxiliary processor toperform floating point mathematical operations, a special-purposemicroprocessor having an architecture suitable for fast execution ofsignal processing algorithms (e.g., digital signal processor), a slaveprocessor subordinate to the main processing system (e.g., back-endprocessor), an additional microprocessor or controller for dual ormultiple processor systems, or a coprocessor. Such auxiliary processorscan be discrete processors or can be integrated with the processor 810.Examples of processors which can be used with the device 800 include,without limitation, the Pentium® processor, Core i7® processor, andXeon® processor, all of which are available from Intel Corporation ofSanta Clara, Calif.

The processor 810 is preferably connected to a communication bus 870.The communication bus 870 can include a data channel for facilitatinginformation transfer between storage and other peripheral components ofthe device 800. The communication bus 870 further can provide a set ofsignals used for communication with the processor 810, including a databus, address bus, and control bus (not shown). The communication bus 870can comprise any standard or non-standard bus architecture such as, forexample, bus architectures compliant with industry standard architecture(ISA), extended industry standard architecture (EISA), Micro ChannelArchitecture (MCA), peripheral component interconnect (PCI) local bus,or standards promulgated by the Institute of Electrical and ElectronicsEngineers (IEEE) including IEEE 488 general-purpose interface bus(GPIB), IEEE 696/S-100, and the like.

The device 800 preferably includes a main memory 820 and can alsoinclude a secondary memory 830. The main memory 820 provides storage ofinstructions and data for programs executing on the processor 810, suchas one or more of the functions and/or modules discussed above. Itshould be understood that programs stored in the memory and executed bythe processor 810 can be written and/or compiled according to anysuitable language, including without limitation C/C++, Java, JavaScript,Pearl, Visual Basic, .NET, and the like. The main memory 820 istypically semiconductor-based memory such as dynamic random accessmemory (DRAM) and/or static random access memory (SRAM). Othersemiconductor-based memory types include, for example, synchronousdynamic random access memory (SDRAM), Rambus dynamic random accessmemory (RDRAM), ferroelectric random access memory (FRAM), and the like,including read only memory (ROM).

The secondary memory 830 can optionally include an internal memory 832and/or a removable storage medium 430, for example a floppy disk drive,a magnetic tape drive, a compact disc (CD) drive, a digital versatiledisc (DVD) drive, other optical drive, a flash memory drive, etc. Theremovable storage medium 430 is read from and/or written to in awell-known manner. The removable storage medium 430 can be, for example,a floppy disk, magnetic tape, CD, DVD, SD card, etc.

The removable storage medium 430 can be a non-transitorycomputer-readable medium having stored thereon computer executable code(i.e., software) and/or data (e.g., for implementing at least a portionof the subject matter described herein). The computer software or datastored on the removable storage medium 430 is read into the device 800for execution by the processor 810.

In alternative embodiments, the secondary memory 830 can include othersimilar means for allowing computer programs or other data orinstructions to be loaded into the device 800. Such means can include,for example, an external storage medium 445 and an interface 440.Examples of the external storage medium 445 can include, for example,but not limited to, an external hard disk drive or an external opticaldrive, or and external magneto-optical drive.

Other examples of the secondary memory 830 can includesemiconductor-based memory such as programmable read-only memory (PROM),erasable programmable read-only memory (EPROM), electrically erasableread-only memory (EEPROM), or flash memory (block oriented memorysimilar to EEPROM). Also included are a removable storage media 430 anda communication interface 850, which allow software and data to betransferred from an external medium 856 to the device 800.

The device 800 can include a communication interface 850. Thecommunication interface 850 allows software and data to be transferredbetween the device 800 and various external devices (e.g. printers),networks, or information sources. For example, computer software orexecutable code can be transferred to the device 800 from a networkserver via the communication interface 850. Examples of thecommunication interface 850 include a built-in network adapter, networkinterface card (NIC), Personal Computer Memory Card InternationalAssociation (PCMCIA) network card, card bus network adapter, wirelessnetwork adapter, Universal Serial Bus (USB) network adapter, modem, anetwork interface card (NIC), a wireless data card, a communicationsport, an infrared interface, an IEEE 1394 fire-wire, or any other devicecapable of interfacing the device 800 with a network or anothercomputing device.

The communication interface 850 preferably implements industrypromulgated protocol standards including, for example, but not limitedto Ethernet IEEE 802 standards, Fiber Channel, digital subscriber line(DSL), asynchronous digital subscriber line (ADSL), frame relay,asynchronous transfer mode (ATM), integrated digital services network(ISDN), personal communications services (PCS), transmission controlprotocol/Internet protocol (TCP/IP), serial line Internet protocol/pointto point protocol (SLIP/PPP), and so on, but can also implementcustomized or non-standard interface protocols as well.

Software and data transferred via Communication Interface 440 aregenerally in the form of electrical communication signals 852. Theelectrical communication signals 852 are preferably provided to thecommunication interface 850 via a communication channel 854. In oneembodiment, the communication channel 854 can be a wired or wirelessnetwork, or any variety of other communication links. The communicationchannel 854 carries the electrical communication signals 852 and can beimplemented using a variety of wired or wireless communication meansincluding, for example, but not limited to, wire or cable, fiber optics,conventional phone line, cellular phone link, wireless datacommunication link, radio frequency (“RF”) link, or infrared link, justto name a few.

Computer executable code (i.e., computer programs or software) is storedin the main memory 820 and/or the secondary memory 830. Computerprograms can also be received via the communication interface 850 andstored in the main memory 820 and/or the secondary memory 830. Suchcomputer programs, when executed, enable the device 800 to perform thevarious functions, such as those described herein.

In this description, the term “computer readable medium” is used torefer to any non-transitory computer readable storage media used toprovide computer executable code (e.g., software and computer programs)to the device 800. Examples of these media include the main memory 820,the secondary memory 830 (including the internal memory 832, theremovable medium 834, and the external storage medium 445), and anyperipheral device communicatively coupled with the communicationinterface 850 (including a network information server or other networkdevice). These non-transitory computer readable mediums are means forproviding executable code, programming instructions, and software to thedevice 800.

In an embodiment that is implemented using software, the software can bestored on a computer readable medium and loaded into the device 800 byway of the removable medium 834, the I/O interface 840, or thecommunication interface 850. In such an embodiment, the software isloaded into the device 800 in the form of the electrical communicationsignals 852. The software, when executed by the processor 810,preferably causes the processor 810 to perform the inventive featuresand functions previously described herein.

In an embodiment, the I/O interface 840 provides an interface betweenone or more components of the device 800 and one or more input and/oroutput devices. Example input devices include, without limitation,keyboards, touch screens or other touch-sensitive devices, biometricsensing devices, computer mice, trackballs, pen-based pointing devices,camera, microphone, and the like. Examples of output devices include,without limitation, cathode ray tubes (CRTs), plasma displays,light-emitting diode (LED) displays, liquid crystal displays (LCDs),printers, vacuum florescent displays (VFDs), surface-conductionelectron-emitter displays (SEDs), field emission displays (FEDs), andthe like.

The device 800 also includes optional wireless communication componentsthat facilitate wireless communication over a voice and over a datanetwork. The wireless communication components can comprise an antennasystem 864, a radio system 862, a baseband system 860, or anycombination thereof. In the device 800, radio frequency (RF) signals aretransmitted and received over the air by the antenna system 864 underthe management of the radio system 862.

In one embodiment, the antenna system 864 can comprise one or moreantennae and one or more multiplexors (not shown) that perform aswitching function to provide the antenna system 864 with transmit andreceive signal paths. In the receive path, received RF signals can becoupled from a multiplexor to a low noise amplifier (not shown) thatamplifies the received RF signal and sends the amplified signal to theradio system 862.

In alternative embodiments, the radio system 862 can comprise one ormore radios that are configured to communicate over various frequencies.In one embodiment, the radio system 862 can combine a demodulator (notshown) and modulator (not shown) in one integrated circuit (IC). Thedemodulator and modulator can also be separate components. In theincoming path, the demodulator strips away the RF carrier signal leavinga baseband receive audio signal, which is sent from the radio system 862to the baseband system 860.

If the received signal contains audio information, the baseband system860 decodes the signal and converts it to an analog signal. Then thesignal is amplified and sent to a speaker. The baseband system 860 alsoreceives analog audio signals from a microphone. These analog audiosignals are converted to digital signals and encoded by the basebandsystem 860. The baseband system 860 also codes the digital signals fortransmission and generates a baseband transmit audio signal that isrouted to the modulator portion of the radio system 862. The modulatormixes the baseband transmit audio signal with an RF carrier signalgenerating an RF transmit signal that is routed to the antenna systemand can pass through a power amplifier (not shown). The power amplifieramplifies the RF transmit signal and routes it to the antenna system 864where the signal is switched to the antenna port for transmission.

The baseband system 860 is also communicatively coupled with theprocessor 810. The processor 810 has access to the main memory 820 andthe secondary memory 830. The processor 810 is preferably configured toexecute instructions (i.e., computer programs or software) that can bestored in the main memory 820 or the secondary memory 830. Computerprograms can also be received from the baseband processor 460 and storedin the main memory 820 or in the secondary memory 830, or executed uponreceipt. Such computer programs, when executed, enable the device 800 toperform the various functions, such as those described herein. Forexample, the main memory 820 and the secondary memory 830 can eachinclude various software modules (not shown).

Various embodiments may also be implemented primarily in hardware using,for example, components such as application specific integrated circuits(ASICs), or field programmable gate arrays (FPGAs). Implementation of ahardware state machine capable of performing the functions describedherein will also be apparent to those skilled in the relevant art.Various embodiments may also be implemented using a combination of bothhardware and software.

Furthermore, those of skill in the art will appreciate that the variousillustrative logical blocks, modules, circuits, and method stepsdescribed in connection with the above described figures and theembodiments disclosed herein can often be implemented as electronichardware, computer software, or combinations of both. To clearlyillustrate this interchangeability of hardware and software, variousillustrative components, blocks, modules, circuits, and steps have beendescribed above generally in terms of their functionality. Whether suchfunctionality is implemented as hardware or software depends upon theparticular application and design constraints imposed on the overallsystem. Skilled persons can implement the described functionality invarying ways for each particular application, but such implementationdecisions should not be interpreted as causing a departure from thescope of the invention. In addition, the grouping of functions within amodule, block, circuit or step is for ease of description. Specificfunctions or steps can be moved from one module, block or circuit toanother without departing from the invention.

Moreover, the various illustrative logical blocks, modules, functions,and methods described in connection with the embodiments disclosedherein can be implemented or performed with a general purpose processor,a digital signal processor (DSP), an ASIC, FPGA or other programmablelogic device, discrete gate or transistor logic, discrete hardwarecomponents, or any combination thereof designed to perform the functionsdescribed herein. A general-purpose processor can be a microprocessor,but in the alternative, the processor can be any processor, controller,microcontroller, or state machine. A processor can also be implementedas a combination of computing devices, for example, a combination of aDSP and a microprocessor, a plurality of microprocessors, one or moremicroprocessors in conjunction with a DSP core, or any other suchconfiguration.

Additionally, the steps of a method or algorithm described in connectionwith the embodiments disclosed herein can be embodied directly inhardware, in a software module executed by a processor, or in acombination of the two. A software module can reside in RAM memory,flash memory, ROM memory, EPROM memory, EEPROM memory, registers, harddisk, a removable disk, a CD-ROM, or any other form of storage mediumincluding a network storage medium. An exemplary storage medium can becoupled to the processor such the processor can read information from,and write information to, the storage medium. In the alternative, thestorage medium can be integral to the processor. The processor and thestorage medium can also reside in an ASIC.

In situations in which the systems discussed here collect personalinformation about users, or can make use of personal information, theusers can be provided with an opportunity to control whether programs orfeatures collect user information (e.g., information about a user'ssocial network, social actions or activities, profession, a user'spreferences, or a user's current location), or to control whether and/orhow to receive content from the content server that can be more relevantto the user. In addition, certain data can be treated in one or moreways before it is stored or used, so that personally identifiableinformation is removed. For example, a user's identity can be treated sothat no personally identifiable information can be determined for theuser, or a user's geographic location can be generalized where locationinformation is obtained (such as to a city, ZIP code, or state level),so that a particular location of a user cannot be determined. Thus, theuser can have control over how information is collected about the userand used by a content server.

Any of the software components described herein may take a variety offorms. For example, a component may be a stand-alone software package,or it may be a software package incorporated as a “tool” in a largersoftware product. It may be downloadable from a network, for example, awebsite, as a stand-alone product or as an add-in package forinstallation in an existing software application. It may also beavailable as a client-server software application, as a web-enabledsoftware application, and/or as a mobile application.

Although a few example implementations have been shown and described,these example implementations are provided to convey the subject matterdescribed herein to people who are familiar with this field. It shouldbe understood that the subject matter described herein may beimplemented in various forms without being limited to the describedexample implementations. The subject matter described herein can bepracticed without those specifically defined or described matters orwith other or different elements or matters not described. It will beappreciated by those familiar with this field that changes can be madein these example implementations without departing from the subjectmatter described herein as defined in the appended claims and theirequivalents.

Various embodiments may also be implemented primarily in hardware using,for example, components such as application specific integrated circuits(ASICs), or field programmable gate arrays (FPGAs). Implementation of ahardware state machine capable of performing the functions describedherein will also be apparent to those skilled in the relevant art.Various embodiments may also be implemented using a combination of bothhardware and software.

Furthermore, those of skill in the art will appreciate that the variousillustrative logical blocks, modules, circuits, and method stepsdescribed in connection with the above described figures and theembodiments disclosed herein can often be implemented as electronichardware, computer software, or combinations of both. To clearlyillustrate this interchangeability of hardware and software, variousillustrative components, blocks, modules, circuits, and steps have beendescribed above generally in terms of their functionality. Whether suchfunctionality is implemented as hardware or software depends upon theparticular application and design constraints imposed on the overallsystem. Skilled persons can implement the described functionality invarying ways for each particular application, but such implementationdecisions should not be interpreted as causing a departure from thescope of the invention. In addition, the grouping of functions within amodule, block, circuit or step is for ease of description. Specificfunctions or steps can be moved from one module, block or circuit toanother without departing from the invention.

Moreover, the various illustrative logical blocks, modules, functions,and methods described in connection with the embodiments disclosedherein can be implemented or performed with a general purpose processor,a digital signal processor (DSP), an ASIC, FPGA or other programmablelogic device, discrete gate or transistor logic, discrete hardwarecomponents, or any combination thereof designed to perform the functionsdescribed herein. A general-purpose processor can be a microprocessor,but in the alternative, the processor can be any processor, controller,microcontroller, or state machine. A processor can also be implementedas a combination of computing devices, for example, a combination of aDSP and a microprocessor, a plurality of microprocessors, one or moremicroprocessors in conjunction with a DSP core, or any other suchconfiguration.

Additionally, the steps of a method or algorithm described in connectionwith the embodiments disclosed herein can be embodied directly inhardware, in a software module executed by a processor, or in acombination of the two. A software module can reside in RAM memory,flash memory, ROM memory, EPROM memory, EEPROM memory, registers, harddisk, a removable disk, a CD-ROM, or any other form of storage mediumincluding a network storage medium. An exemplary storage medium can becoupled to the processor such the processor can read information from,and write information to, the storage medium. In the alternative, thestorage medium can be integral to the processor. The processor and thestorage medium can also reside in an ASIC.

While certain embodiments have been described above, it will beunderstood that the embodiments described are by way of example only.Accordingly, the systems and methods described herein should not belimited based on the described embodiments. Rather, the systems andmethods described herein should only be limited in light of the claimsthat follow when taken in conjunction with the above description andaccompanying drawings.

What is claimed:
 1. A system, comprising: a hardware processor; adatabase; an executable software module that, when executed by the atleast one hardware processor, is configured to: receive an indicationfrom a messaging client associated with a first caregiver activelyaffiliated with a first covered entity to include a second caregiveractively affiliated with a second covered entity in a conversation ownedby the first covered entity; determine whether the affiliation betweenthe first caregiver and the first covered entity is linked with aconversation sharing privilege; and in response to a determination thatthe affiliation between the first caregiver and the first covered entityis linked with a conversation sharing privilege, include the secondcaregiver as a participant in the conversation owned by the firstcovered entity.
 2. The system as recited in claim 1, wherein in responseto the determination that the affiliation between the first caregiverand the first covered entity is linked with a conversation sharingprivilege, the executable software module is further configured toattribute ownership of the conversation to the first covered entity andthe second covered entity.
 3. The system as recited in claim 1, whereinin response to the determination that the affiliation between the firstcaregiver and the first covered entity is not linked with a conversationsharing privilege, the executable software module is configured to:exclude the second caregiver as an authorized participant in theconversation owned by the first covered entity; and attribute ownershipof the conversation to the first covered entity but not the secondcovered entity.
 4. The system as recited in claim 3, wherein in responseto the determination that the affiliation between the first caregiverand the first covered entity is not linked with a conversation sharingprivilege, the executable software module is further configured to causethe messaging client associated with the first caregiver to notify thefirst caregiver that the first caregiver does not have conversationsharing privilege for the first covered entity.
 5. The system as recitedin claim 3, wherein the conversation comprises a patient-centeredconversation relating to a specific patient.
 6. The system as recited inclaim 1, wherein the indication includes a selection of the secondcovered entity.
 7. The system as recited in claim 6, wherein theexecutable software module is configured to: provide, to the messagingclient, a plurality of caregivers actively affiliated with the secondcovered entity; and receive, from the messaging client, a selection ofthe second caregiver.
 8. The system as recited in claim 1, wherein theindication includes a unique communication enabling personal identifierassociated with the second caregiver.
 9. A system, comprising: ahardware processor; a database; an executable software module that, whenexecuted by the at least one hardware processor, is configured to:receive an indication from a messaging client associated with a firstcaregiver actively affiliated with a first covered entity to transferownership of a conversation from the first covered entity to a secondcovered entity; determine whether the affiliation between the firstcaregiver and the first covered entity is linked with a conversationtransfer privilege; and in response to a determination that theaffiliation between the first caregiver and the first covered entity islinked with a conversation transfer privilege, attribute ownership ofthe conversation to the second covered entity and not the first coveredentity.
 10. The system as recited in claim 9, wherein in response to thedetermination that the affiliation between the first caregiver and thefirst covered entity is linked with a conversation transfer privilege,the executable software module is further configured to remove asparticipants in the conversation one or more caregivers not activelyaffiliated with the second covered entity.
 11. The system as recited inclaim 9, wherein in response to the determination that the affiliationbetween the first caregiver and the first covered entity is linked witha conversation transfer privilege, the executable software module isfurther configured prohibit caregivers not actively affiliated with thesecond covered entity from accessing message data comprising theconversation.
 12. The system as recited in claim 9, wherein theexecutable software module is configured to: in response to adetermination that the affiliation between the first caregiver and thefirst covered entity is not linked with a conversation transferprivilege, continue attributing ownership of the conversation to thefirst covered entity.
 13. The system as recited in claim 12, wherein inresponse to a determination that the affiliation between the firstcaregiver and the first covered entity is not linked with a conversationtransfer privilege, the executable software module is further configuredto cause the messaging client associated with the first caregiver tonotify the first caregiver that the first caregiver does not haveconversation transfer privilege for the first covered entity.
 14. Amethod, comprising: receiving an indication from a messaging clientassociated with a first caregiver actively affiliated with a firstcovered entity to include a second caregiver actively affiliated with asecond covered entity in a conversation owned by the first coveredentity; determining, using a hardware processor, whether the affiliationbetween the first caregiver and the first covered entity is linked witha conversation sharing privilege; and in response to a determinationthat the affiliation between the first caregiver and the first coveredentity is linked with a conversation sharing privilege, including thesecond caregiver as a participant in the conversation owned by the firstcovered entity.
 15. The method as recited in claim 14, furthercomprising in response to the determination that the affiliation betweenthe first caregiver and the first covered entity is linked with aconversation sharing privilege, attributing ownership of theconversation to the first covered entity and the second covered entity.16. The method as recited in claim 14, further comprising: in responseto the determination that the affiliation between the first caregiverand the first covered entity is not linked with a conversation sharingprivilege: excluding the second caregiver as an authorized participantin the conversation owned by the first covered entity; and attributingownership of the conversation to the first covered entity but not thesecond covered entity.
 17. The method as recited in claim 16, furthercomprising: in response to the determination that the affiliationbetween the first caregiver and the first covered entity is not linkedwith a conversation sharing privilege, causing the messaging clientassociated with the first caregiver to notify the first caregiver thatthe first caregiver does not have conversation sharing privilege for thefirst covered entity.
 18. The method as recited in claim 16, wherein theconversation comprises a patient-centered conversation relating to aspecific patient.
 19. The method as recited in claim 14, wherein theindication includes a selection of the second covered entity.
 20. Themethod as recited in claim 19, further comprising: providing, to themessaging client, a plurality of caregivers actively affiliated with thesecond covered entity; and receiving, from the messaging client, aselection of the second caregiver.
 21. The method as recited in claim14, wherein the indication includes a unique communication enablingpersonal identifier associated with the second caregiver.
 22. A method,comprising: receiving an indication from a messaging client associatedwith a first caregiver actively affiliated with a first covered entityto transfer ownership of a conversation from the first covered entity toa second covered entity; determining, using a hardware processor,whether the affiliation between the first caregiver and the firstcovered entity is linked with a conversation transfer privilege; and inresponse to a determination that the affiliation between the firstcaregiver and the first covered entity is linked with a conversationtransfer privilege, attributing ownership of the conversation to thesecond covered entity and not the first covered entity.
 23. The methodas recited in claim 22, further comprising: in response to thedetermination that the affiliation between the first caregiver and thefirst covered entity is linked with a conversation transfer privilege,removing as participants in the conversation one or more caregivers notactively affiliated with the second covered entity.
 24. The method asrecited in claim 22, further comprising: in response to thedetermination that the affiliation between the first caregiver and thefirst covered entity is linked with a conversation transfer privilege,prohibiting caregivers not actively affiliated with the second coveredentity from accessing message data comprising the conversation.
 25. Themethod as recited in claim 22, further comprising: in response to adetermination that the affiliation between the first caregiver and thefirst covered entity is not linked with a conversation transferprivilege, continuing attributing ownership of the conversation to thefirst covered entity.
 26. The method as recited in claim 25, furthercomprising: in response to a determination that the affiliation betweenthe first caregiver and the first covered entity is not linked with aconversation transfer privilege, causing the messaging client associatedwith the first caregiver to notify the first caregiver that the firstcaregiver does not have conversation transfer privilege for the firstcovered entity.